The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In the field of databases, clients send database commands, such as Structured Query Language (SQL) statements, to a database server for execution. Each of the SQL statements is sent to the database server in a separate call to the interface of the database server.
In the past, while executing client programs with processing logic statements, all the SQL statements were sent one-by-one to the server and executed. When each SQL statement is sent to the server, transmission information is also sent from the client to the server. Such transmission information may include, for example:                1. Function code generated from the SQL statement.        2. A cursor identification indicating whether the statement executed previously.        3. A length of the SQL statement.        4. The text of the SQL statement.        5. Flags for identifying the SQL statement.        6. The length of an input array containing various input parameters.        7. The actual input array.        8. A list of binds for parameter values that need to be bound to the SQL statement.        9. A number identifying how many binds are being sent for the SQL statement.        10. A list of defines for defining variables to which the parameter values are to be bound.        11. A number indicating the number of the defines.        12. The length of the transaction context for the SQL statement.        13. The actual transaction context for the SQL statement.Additional transmission information may also be sent along with the SQL statement. The transmission information is sent to server for every SQL statement. The present inventors have recognized that at least some of the transmission information, such as the length of the transaction context and the actual transaction context, is common to all the SQL statements. In this specification, the phrase database statement is generic to a query, any place a database statement is mentioned the word “query” may be inserted instead to obtain a more specific example. For example, a database statement may be any SQL statement (SQL DDL, SQL DML, or an SQL query) or PL/SQL statement that can be invoked by a client (such as an anonymous block, an EXECUTE IMMEDIATE statement, or a CALL statement to a PL/SQL procedure/function).        
Prior SQL engines do not concurrently process more than one database statement per session at a time. Although parallel processing may be performed for instructions associated with the same database statement (e.g., an insert statement may be executed by causing several slave processes to insert in parallel), parallel processing is not performed across database statements. Similarly, query slaves or database statement slaves may perform various tasks in parallel that correspond to a single query or database statement, but do not perform in parallel tasks associated with different database statements. Consequently, although instructions associated with the same database statement may be processed in parallel, instructions associated with different database statements are processed sequentially.
Although it may be possible to effect parallel execution of different database statements by writing code to essentially start concurrent client sessions and invoking the database server from each of them, concurrent execution in this fashion is cumbersome.